Mobile gaming system

ABSTRACT

A system and method for providing mobile lottery gaming over a wireless mobile device/handset. The system and method permit a user of a mobile wireless device to play a lottery game electronically. The system will be designed such that various client services (banking, wallet, and gaming) can employ the existing infrastructure to perform its functions without compromising on essential features such as ease of use and security. Once a user is registered onto the system they can utilize an identification code to authorize the downloading of lottery games from a server to their mobile device. A financial account enables the user to electronically pay for the lottery games. Notification of the results of the lottery games can be made by e-mail, SMS or an IVR call.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation-in-part of U.S. patent applicationSer. No. 12/099,901 filed Apr. 9, 2008, entitled Mobile Gaming System,the contents of which is incorporated herein by reference.

FIELD OF THE INVENTION

The current invention relates to a mobile gaming system on wirelessnetworks and a method associated therewith. More particularly thepresent invention relates to lottery gaming on wireless communicationdevices and methods of implementing these games.

BACKGROUND OF THE INVENTION

There are many ways of playing lottery games. The most popular ispurchasing a lottery ticket from a vendor at a local store or otherestablishment. The results of the lottery can be tracked by thepurchaser, after the actual lottery, by watch in TV, listing to theradio or seeing the results posted at the establishments which sell thelottery tickets.

This conventional method of playing lottery games is burdensome totoday's highly mobile individual. This method requires the individual togo out of their way to find a vendor or establishment that sells lotterytickets. The purchaser must normally wait in line to make his or herpurchase of one or more tickets. In addition, if an individual isresting at home or is at work and decides to play the lottery he or shemust complete the task at hand and travel to a location which sellslottery tickets, stand in line and purchase the lottery tickets.

The reduction in size of the personal computer has resulted in handheldPersonal Digital Assistants (PDA) and cellular telephone with thecapability to download games and other types of software. These deviceshave enabled a user to download many popular games such as solitaire,poker, video slots and other lottery games. At first these games wereembedded in the devices by the Original Equipment Manufacturer (OEM).Later the games could be purchased as software and loaded into personalcomputers. From these PCs they could be downloaded through a cableconnection to the PDAs. Eventually wireless communications replaced hardwire connections and the games could be wirelessly downloaded into thehandheld devices and cell phones.

There are currently many different handheld devices and cellular phoneswhich employ many different platforms on which these devices operate. Atthis time there are no standards between the platforms and therefore thegames must be specifically designed for the individual platforms. Thisis very costly. The different platforms may not allow a game designedfor a certain platform to operate correctly on another platform. Inaddition, if an individual decides to utilize a different PDA orcellular phone then they must repurchase all the games they had is theirprevious PDA or cell phone. This becomes prohibitively expensive and maysway the individual's decision to purchase the game in the first place.

There are also differences between some devices and the resourcesavailable for the devices such as Windows® for PCs and OSX® for Applecomputers. The games must include software which is compatible withthese different operating systems. These differences further add to theincompatibility between different handheld devices and games which canbe downloaded onto these devices.

When cellular phones are employed as a platform there are a further setof game distribution challenges. The cellular phone companies normallyemploy different transmission standards for their wireless networkswhich are only compatible with phones specifically designed to operatewith these standards. Therefore, to be compatible with the differentcell phones the games must be designed to operate with each of thesedifferent standards.

Mobile lottery gaming on a Wireless Mobile device/handset are playedusing the technologies supported by the device. The games may beinstalled over the air, they may be loaded onto the device with a cable,or they may be embedded on the handheld devices by the OEM or by themobile operator. There are many challenges with mobile lottery gamedevelopment including nonstandard platforms with too many platformspecific incompatibilities, multiple platforms with inter-operabilityissues, differences in the devices and their resources, and distributionchallenges to deploy with cell phone networks.

SUMMARY OF THE INVENTION

The disclosed embodiments provide a system and method for providinglottery like games over a wireless network. The system and method permita user of a mobile wireless device to play a lottery game electronicallywith the feel of a real game. Once a user is registered onto the systemthey can utilize an identification code to authorize the downloading oflottery games from a server to their mobile device. A financial accountenables the user to electronically pay for the lottery games.Notification of the results of the lottery games can be made by e-mail,SMS or an IVR call.

Accordingly, it is an objective of the instant invention to provide asystem for playing lottery like games over a wireless network utilizinga mobile wireless device which the user currently owns.

It is a further objective of the instant invention to provide a systemfor playing lottery like games over a wireless network wherein aproprietary mobile device is not required for playing mobile lotterygames or different games that are available over the wireless network.

It is another objective of the instant invention to allow the user theeasiest mode of playing the lottery game that the user is familiar with.

It is yet another objective of the instant invention to provide a systemfor playing lottery like games over a wireless network utilizing anapplication based system.

It is a still further objective of the invention to provide a system forplaying lottery games over a wireless network utilizing an interactivevoice response system.

It is still yet another objective of the instant invention to provide asystem for playing lottery like games over a wireless network utilizinga WAP (Wireless Application Protocols) browser to allow a mobile phoneto access the Internet.

Other objects and advantages of this invention will become apparent fromthe following description taken in conjunction with any accompanyingdrawings wherein are set forth, by way of illustration and example,certain embodiments of this invention. Any drawings contained hereinconstitute a part of this specification and include exemplaryembodiments of the present invention and illustrate various objects andfeatures thereof.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 is an overall view of the architecture for a mobile gamingsystem;

FIG. 2 is a diagram of a the architecture for a client applicationgaming system;

FIG. 3 is a diagram of the architecture for a gaming server applicationgaming system;

FIG. 4 is a diagram of a model view controller;

FIG. 5 is a registration form on a website;

FIG. 6 is a flowchart for a application based gaming system;

FIG. 7 is a flowchart for an IVR based gaming system;

FIG. 8 is a flowchart for a WAP based gaming system;

FIG. 9 is a flowchart for a SMS based gaming system;

FIG. 10 is an illustrative diagram of the ApplicationRegistry interface;

FIG. 11 is a client state transition diagram;

FIG. 12 is a server state transition diagram;

FIG. 13 is a structure of binary encoding;

FIG. 14 is an illustration of a header+payload;

FIG. 15 is an illustration of the Transport Engine and TransportEncoding Services;

FIG. 16 is an illustration of two layers communicating via TCP/IP:

FIG. 17 is an illustration of SMS datagrams;

FIG. 18 is a format for the payload;

FIG. 19 depicts the client/server message structure; and

FIG. 20 depicts the transport layer.

DETAILED DESCRIPTION OF THE INVENTION

A presently preferred embodiment of the instant invention is anapplication based mobile lottery gaming system. This system permits theplayer or user to have a GUI (graphic user interface) based interfacewith a mobile device to play games and contact a server. The mobiledevice can be, but are not limited to, a PDA (personal digitalassistant) with a wireless connection, a laptop computer with a wirelessconnection or a cell (mobile) phone. The GUI interface permits theuser/player to establish a more secured, easy to learn and interruptibleconnection with a server. An example of a mobile lottery gaming systemis illustrated in FIG. 1 depicting an overall architecture of thesystem. The system will be designed such that various client services(banking, wallet, and gaming) can employ the existing infrastructure toperform its functions without compromising on essential features such asease of use and security. A mobile device 11 communicates with an accessnetwork 13. The access network communicates over the Internet 15 bycoupling through a radio access network to an application gateway 19 viaa PDSN 21. The Application gateway 19 coupled to a core banking module23.

Referring to FIG. 6, the gaming application is launched 10 on a mobiledevice which allows the user to register. The registration process 12allows the user establish an account with a server. The user can themlogin using their passcode and/or selected image 14. If the incorrectpasscode and/or image is entered 16 the user is instructed to enter thisinformation again. After a number of unsuccessful login attempts, forexample 5, the user is sent to the end of the program and not permittedto play the game 18. If the user wants to continue they must repeat theregistration process 12 again. Once the user has logged in they canchoose the game they wish to play for the gaming application menu 20.For example the user may wish to play a PICK 3 Lottery game. Next at 22the user will provide the arguments or select the number they wish toplay on the keypad of the mobile device or other data entering device.For example the user may enter “02”, “34” and “45” on the keypad. Thetransaction is confirmed at step 24. Depending on the game which isselected there will either be an immediate draw of the winning numbers26 or a date will be given on which the winning numbers are to be drawn28. If the drawing is at a later date the user can check back on theirmobile device for the winning number or can check other sources such asthe television, a lottery terminal, the newspaper, etc. The gamingapplication is then ended at 30.

The architecture for application based lottery gaming is designed toaccommodate various application modules. The preferred embodiment isdivided into two models. A Client Application model and a Gaming Servermodel.

The Application model architecture is designed as a stack of protocols.FIG. 2 is an example of the Client Application model architecture. Thereare four layers in this model. Each layer has a set of functions toperform. The application layer 32 consists of multiple game applications34, 36, 37, 38, etc. The applications are connected to the lower layersvia two way communication for their function. Each of these gameapplications will be implemented based on a Model-View-Controller (MVC)paradigm. The MVC diagram is illustrated in FIG. 4. The Model 40 holdsthe data for the application. The View 42 is responsible to display thedata to the user. The Controller 46 registers and receives events fromthe application router. Upon receipt of the event, the controller 46will modify the data in the model 40 and notifies the view 42. The view42 will update its display of data to the user. The applications willavail of the pre-negotiated layer services that it wishes to employ,such as security services (NULL encryption, Custom or SSL Encryption),Message Encoding (ComML or Binary Encoding) and transport mechanism(TCP/IP or SMS). An instance of each of these services will be createdupon request.

The presentation layer 50 consists of essentially 3 components;Cryptographic Services 52, an Application Router 54 and Message EncodingServices 56.

Cryptographic services 52. The Security Services comprise a group ofsecurity modules which provide the required security during a datacommunication. It includes the most commonly used cryptographicservices. Application router 54 receives data from both the applicationlayer 32 and the transport layer 58. An application registers for eventsfrom the application router 54. An application will send a message viathe application router. The application router will then invoke theMessage Encoder module 56 for appropriate encoding, such as ComML. Itthen invokes the appropriate security module for encrypting the ComMLmessage. The encrypted payload is then passed on to the transport layer58. The application encoder facilitates encoding and decoding ofmessages which are invoked by the application router. In a preferredembodiment the encoder supports ComML encoding. Alternative encodingschemes can also be supported in this framework. Client/Servercommunication can take place by means of protocol. However, the protocolalso needs to follow the pre-agreed data encoding in order to properlycommunicate. Supports two such data encoding schemes: Binary Encodingand ComML Encoding. The Presentation Layer maintains a State Machine inorder to maintain shared State between the Client and the Server.

The Application Router is responsible for routing Commands to a specificmodule, as well as ensuring that Commands sent out from the modules arecorrectly encapsulated and the proper encryption procedures are applied.An application registers for events from the application router. Anapplication will send a message via the application router. Theapplication router will then invoke the Message Encoder module forappropriate encoding (such as ComML). The application router theninvokes the appropriate security module for encrypting the ComMLmessage. The encrypted payload is then passed on to the transport layer.

The Transport layer 58 utilizes a transport engine 60 for communicationbetween the application router 54 a network interface 62, and atransport encoding services 61 and a gaming server 63 using GPRS/1xEVDO.The Network interface layer 62 uses the underlying Air Interfacetechnology for the mobile device to communicate with the gaming server.It can be either a GPRS network or a 1xEV-DO network.

Referring to FIGS. 11 and 12, a state machine stores the status ofclient and server at a given time and can operate on input to change thestatus and/or cause an action or output to take place for any givenchange. Client and Server maintain shared states between themselves. TheState Machine for the Client and Server will reside at the PresentationLayer. At any given instance of time the client will be in the followingthree states:

Inactive State: This state is the initial state of the Client uponinstallation. The server instance will also be in the Inactive State. Inthis state, the device can either send a RequestConfig Command to theserver or wait for a ConfigurationStart Command.

Setup State: In this state, the device and the network are in theprocessing of negotiating various modules and their parameters. Theconfiguration can only be done by the server and the client can acceptit, reject it or propose an alternative. If the Setup state fails, itwill transition back to Inactive State.

Active State: In this state, the device and network are ready toexchange application data. The server is ready to accept Commands onbehalf of applications in order to process it via 3rd party applicationservers.

A Server architecture is illustrated in FIG. 3. The server architectureis designed as a stack of protocols. There are four layers in the gameserver model. Each layer has a set of functions to perform. Theapplication layer 64 consists of multiple application services, eachserving a specific application or game 66, 68, 70, 71 etc. Eachapplication service communicates with a backend gaming system 72designed for a specific game, which is part of the business layer. Thebackend gaming system 72 employs authentication service 73 based upon adatabase 65.

The presentation layer 76 also consists of 3 components: CryptographicServices 81, an Application Router 83 and Message Encoding Services 85.Cryptographic services 81 comprise a group of security modules whichprovide the required security during a data communication. Applicationrouter 83 receives data from both the application layer 64 and thetransport layer 78. An application will send a message via theapplication router. The application router will then invoke the MessageEncoder module 85 for appropriate encoding, such as ComML. It theninvokes the appropriate security module for encrypting the ComMLmessage. The encrypted payload is then passed on to the transport layer78.

Message encoding services 85 facilitates encoding and decoding ofmessages which are invoked by the application router. In a preferredembodiment the encoder supports ComML encoding. Alternative encodingschemes can also be supported in this framework.

The Transport layer 78 utilizes a transport engine 87 for communicationbetween the application router 85 a network interface 80, and atransport encoding services 89, in the server architecture the interfaceis preferably by Ethernet 91.

Below is an example of the ComML encoding used between the clientarchitecture and the server architecture.

<!-- Root or Element --> <!ELEMENT ComML (ComHdr, ComBody)> <!ELEMENTComHdr (ProtoVersion, Random, SessionID, MsgSeq, Destination)> <!ELEMENTComBody ((ConfigurationStart | RequestConfig | Configure | Commit|ConfigurationComplete | Page | Get | Put | Alert | Results)+, Final?)><!--Protocol Version. The protocol version supported by thecommunicating parties--> <!ELEMENT ProtoVersion (#PCDATA)> <!--SessionID. Each session can comprise of a multiple client/server interactions.They will be represented by this unique Session ID--> <!ELEMENTSessionID (#PCDATA)> <!--Message Sequence Number--> <!ELEMENT MsgSeq(#PCDATA)> <!--Message Sequence Number--> <!ELEMENT Random (#PCDATA)><!--The Destination of the Message--> <!ELEMENT Destination (Type,SubType)> <!ELEMENT Type (#PCDATA)> <!ELEMENT SubType (#PCDATA)><!--ConfigurationStart is sent by the Server to the client. ConfigurationStart will contain a MessageID, and Entity List--><!ELEMENT ConfigurationStart ((CmdID, Entity+))> <!--RequestConfig issent by the Client to the Server.  RequestConfig will contain aMessageID, and Entity List--> <!ELEMENT RequestConfig ((CmdID,Entity+))> <!--ConfigurationComplete is sent by the Server to theclient.  ConfigurationComplete will contain a MessageID, and EntityList--> <!ELEMENT ConfigurationComplete ((CmdID, Entity+))><!--Configure is sent by the Server to the client.  Configure willcontain a MessageID, and Entity List--> <!ELEMENT Configure ((CmdID,Entity+))> <!--Commit is sent by the Server to the client.  Commit willcontain a MessageID, and Entity List--> <!ELEMENT Commit ((CmdID,Entity+))> <!--Alerts are sent by the Server to the client uponregistration by the  Client. Alerts will contain a CommandID, and EntityList--> <!ELEMENT Alert ((CmdID, Entity+))> <!--Page is sent by theServer, using the SMS mode to request the Client  for a ConnectionSetup. Page will contain a CommandID, and  Entity List--> <!ELEMENT Page(CmdID, Entity+)> <!--Get Command can be used either by the Client orthe Server.  Get will contain a CommandID, Optional Credentials andItemList--> <!ELEMENT Get ((CmdID, Entity+))> <!--Put Command can beused either by the Client or the Server.  Put will contain a CommandID,Optional Credentials and ItemList--> <!ELEMENT Put ((CmdID, Entity+))><!--Results will contain the execution result of Get and Put Command .The CmdID MUST match that of command relates to.  Results will contain aCommandID, Optional Credentials and  ItemList--> <!ELEMENT Results(CmdID, MsgRef, Status)> <!-- Entity element type --> <!ELEMENT Entity(ItemEntity?, CustomEntity? )> <!ELEMENT ItemEntity (Name, Meta, Data)><!ELEMENT CustomEntity (Meta, Data)> <!-- Contains the Status Code--><!-- Represents the CommandID for the Data --> <!ELEMENT CmdID(#PCDATA)> <!-- Represents the MessageReference for the Data --><!ELEMENT MsgRef (#PCDATA)> <!ELEMENT Status (Meta, Data)> <!--Represents the Meta Type for the Data --> <!ELEMENT Meta (#PCDATA)> <!--Represents the Data --> <!ELEMENT Data (#PCDATA)> <!--The Final Nodedenotes the Final Transaction for this session. Any new communicationMUST begin as a new Session--> <!ELEMENT Final (EMPTY)> <! - - End ofBody Definitions- -> <! - - 2nd Level Definitions for Hdr - -> <! - -Application Target. Used by the Application Router - -> <!ELEMENTAppTarget (AppID, AppName?)> <!- - Application Source. Used by theApplication Router - -> <!ELEMENT AppSource (AppID, AppName?)> <! - - AUnique Application ID is used to distinguish each Application - -><!ELEMENT AppID (#PCDATA)> <! - -Optional Application Name - -><!ELEMENT AppName (#PCDATA)> <! - - Data represents the actual Data foran element - -> <!ELEMENT Data (#PCDATA)> <! - - Item element type - -><!ELEMENT Item (Meta?, Data)> <!- - Contains the Status Code - -><!ELEMENT Status (#PCDATA)> <! - - End of 2nd Level Definitions - ->

The Protocol Layers for both Client and Server architecture is furtherdescribed as follows. Referring to FIG. 10, the Application Layerconsists of various modules (gaming modules, banking modules, etc) whichprovide user interaction on the Client side. The Server ApplicationLayer modules will provide services to the modules on the Client.

The ApplicationRegistry is the interface for all the Application Modulesto the Router. All application modules MUST register with the Registry.The Application Layer, which comprises of the AppRegistry along with allthe application modules, is collectively called as “The Communicator”.The Presentation Layer modules, the Transport Layer modules arecollectively called as “The Connector”.

The Application Registry also controls the invocation of variousapplication modules. When the user invokes the application, an instanceof the Application Registry is created. The Application Registry in-turninvokes the default application, the Default application module for theApplication registry is the GI_Gaming.Console. This module, uponinstantiation, challenges the user for a 4 digit PASSCODE.

The application layer will consist of multiple applications. Theapplication will avail of the lower layers for its functions. Eachapplication will be implemented based on a Model-View-Controller (MVC)paradigm.

For the Server Side: The Application Layer consists of multipleapplication services, each servicing a specific application or game.Each of the application service communicates with a backend gamingsystem designed for a specific game, which is part of the businesslayer.

The Application Encoder facilitates encoding and decoding of messageswhich are invoked by the Application router. Currently the encodersupports ComML encoding. Alternative encoding schemes may also besupported in this framework including Binary Encoding and ComMLEncoding. The structure of binary encoding is shown in FIG. 13.Referring to FIG. 14, set forth is the header+payload.

ComML Encoding: The ComML consists of ComHdr and ComBody

ComHdr: Header Encoding Protocol Version: Presently in Use: 1

Random: (1 byte) Each entity (client or server) must generate a 1 byterandom number using a cryptographically secure pseudo-random numbergenerator for every transaction.

Session ID (4 bytes) Each communication between the client and servercomprises of a unique session ID. The Session ID SHALL be of 4 bytes inlength. A general convention to construct a unique session ID is asfollows: Each session ID generated by the client MUST be an odd number;Each session ID generated by the Server MUST be an even number; Serverand Client MUST remember the last session ID generated; All Session IDstransmitted must be in network byte order

Message Sequence (1 byte) Each message within a session MUST have aunique Message sequence. The originator of the session will begin with amessage sequence 1. Subsequently, all messages will have an incrementalmessage sequence number. For Eg: (if client is the originator)Client→Server Message Sequence: 1 (for message 1); Server→Client MessageSequence: 2 (for message 2).

Destination Type (1 byte) The Destination Module Type refers to the Typeof the Module to which the Command(s) is destined to. Refer to Table 8.1for a list of Destination Element.

Destination Subtype (2 bytes) This represents the Destination SubtypeModule. Refer to Table 8.2 for a list of Destination Instances. Both theDestination Type and the Destination Subtype are used by the applicationrouter on either side to route messages to the destination module.

ComBody—Body of the information/message sent. The ComBody consists ofcommands destined to a specific module, based on the Destination Typeand Destination Subtype.

The Transport Layer provides transparent transfer of data between endsystems and move PDUs of data between the two communicating systems. Thetransport service is said to perform “peer to peer” communication, withthe remote (peer) transport entity. Referring to FIG. 15, the TransportLayer consists of 2 components: Transport Engine & Transport EncodingServices.

The Transport Engine takes care of transmission and reception of thepayload. Currently TCP/IP and SMS transport engine instances aresupported. TCP/IP transport engine will make use of either TCP or UDPsockets for communication. Below is the Transport Layer ModuleDescription.

TransportServiceModule Type: It is a Module Type that provides transportrelated services to the upper layer. Module Types are either defined asinterfaces or as abstract classes.

TCPService Module Subtype: It is a class inherited from theTransportServiceModule Type. Objects are instantiated from this Subtypewhose reference will be of TransportServiceModule Type. This instancewill be instantiated when the client server communication uses TCPtransport Service.

SMSService Module Subtype: It is a class inherited from theTransportServiceModule Type. Objects are instantiated from this Subtypewhose reference will be of TransportServiceModule Type. This instancewill be instantiated when the client server communication uses SMStransport Service.

The Transport Encoding Services is responsible for encoding and decodingof the transport layer payload. An instance of the required encoder iscreated by the respective engine.

TransportEncoderModule Type: It is a Module Type that provides transportrelated services to the upper layer. Module Types are either defined asinterfaces or as abstract classes.

TCPEncoder Module Subtype: It is a class inherited from theTransportServiceModule Type. Objects are instantiated from this Subtypewhose reference will be of TransportServiceModule Type. This instancewill be instantiated when the client server communication uses TCPtransport Service.

SMSEncoder Module Subtype: It is a class inherited from theTransportServiceModule Type. Objects are instantiated from this Subtypewhose reference will be of TransportServiceModule Type. This instancewill be instantiated when the client server communication uses SMStransport Service.

Client Inter-Process Communication. The application on the client istypically broken down into two distinct components: The Connector, whichruns as a service and The Communicator which runs upon request, eitherby the user (opening the application) or by the Connector (when anasynchronous message or event is received). The Connector implements thePresentation Layer and the transport layer, whereas The Communicatorimplements the application layer. The two layers communicate via TCP/IPas shown in FIG. 16.

Common Client and Server Components: The Transport Layer consists of thefollowing components: SMSListener, which listens to incoming SMSmessages; and TCP/UDP Sockets, which makes TCP/UDP Connection.

Referring to FIG. 17, the SMS Listener will listen for incoming SMSdatagrams and will also be responsible in sending out an SMS datagramsto the destination. It takes care of fragmentation of SMS Packet duringtransmission and de-fragmentation to create an SMS Packet duringreceipt.

Identifier: A unique identifier is given by the sender to an SMS Packet.Each SMS Datagram, which comprises a part of the SMS Packet, willcontain the same identifier. This will be used by the receiver forde-fragmentation. Length: The Length of the SMS Datagram payload.Fragment Offset: Represents the 6 bits (Bit 1 through Bit 6) thatrepresents the offset into the fragmented SMS packet. The sender startsthe fragment with count=0 for the 1^(st) fragment. Last Fragment Bit:This flag is set to 1 if the SMS message represents the last fragment.All other fragments will have the value=0. Reserved—Currently not used.

SMS Packet: SMS Packet is defined as a complete entity which can bepossibly fragmented. The upper layers will provide an SMS packet to betransmitted to the SMSListener. SMS Datagram: SMS Datagram is defined asa payload of 1 SMS message. It could comprise of a fragmented SMS Packetor a complete SMS packet, depending upon the size of the SMS Packet. SMSMessage: SMS Message comprises of header and payload. The payload willbe and SMS Datagram.

The TCP/UDP Sockets takes care of the TCP/IP communication between theclient and the server. It makes use of TCP reliable streamcommunication. Since TCP is employed, fragmentation, retransmission, etcwill be taken care by the TCP stack implementation on a given platform.The Data format for the payload is shown in FIG. 18 will be as follows:Start Flag (SF): this flag indicates the start of the TCP frame; EndFlag (EF): this flag indicates end of TCP frame; Payload:Information/Data.

The Client and Server will communicate using either ComML or Binaryencoding scheme, the client/server messages will contain the structureshown in FIG. 19. The data representation contains a Header section anda Body Section.

The Business Layer (server only) consists of entities that contain thebusiness logic of various games and applications. The application layerwill interact with business layer modules to provide a comprehensiveservice to clients.

Referring to FIG. 20, the Network Interface layer is the most basicnetwork layer, providing only the means of transmitting raw bits ratherthan packets over a physical data link connecting network nodes. NetworkInterface Layer gets the data from the upper layer (Transport Layer) andmakes a peer to peer connection between the client and server using TCP(Sockets) or SMS (Binary Format) to send and receive data.

An example of the above applications will now be described. The userregisters on the gaming server registration website for the first time.During registration the user will be asked to select a Passcode orPassword that will be used for all future transactions. FIG. 5 is anexample of a registration form template. The user will enter their nameat 82. The user will then enter their mobile device identificationnumber, for example their cell phone number, at 84. They can enter anyother mobile identification number which the system can recognize. Nextthe user will enter their credit card number at 86. Next the expirationdate of the credit card will be entered at 88. The user will next enterhis/her date of birth at 90. The user will then select a passcode orpassword at 92. An image to be associated with their passcode/passwordcan then be selected at 94. An agreement stating the rules andconditions of the game can then be presented to the user. If the useragrees to these conditions they will check the “Verify Agreement” box96. The agreement is optional and may not be employed. If the user issatisfied with all the information they entered, they will then click onthe “Accept” button 98. If they need to change some of the informationthey will click the “Reject” button 100 and enter new information. Aspart of the registration process the client and the server will followthe Asymmetric key encryption procedure of Passcode/Passwordverification. The server will send the encrypted XML configuration fileto the client immediately after successful registration. This methodwill remove the need for the client application to communicate with theserver each time the user logs in. The user will enter thePasscode/Password. The server will receive the Passcode/Password andencrypt it using the Asymmetric encryption algorithm. The server willthen send the digitally signed XML configuration file with all theinformation including its Public Key, Digital signature and he encryptedPasscode/Password to the client. The client will store this informationin their mobile device. Every time the user logs in, the clientapplication prompts for a Passcode/Password. The Passcode/Passwordverification will happen at the client side since the XML configuration(encryption details) file is already present in the client's device.

The client application can be deployed in the following ways. The usercan receive a SMS with a HTTP/WAP link. With a HTTP link the user candirectly click on the link and download the application to the mobiledevice and install the application. With a WAP link the user can open aWAP browser and download the application and install it. The user canalso insert a smart card into the mobile device with the clientapplication loaded into it.

After the client application has been installed the user can launch theapplication to start playing the games. In the application menu on theclient device the user can choose from the different games which areavailable. Once the user chooses the game from the menu the user thenlogs in by using his/her Passcode/Password each time before playing.Once the user starts playing the lottery game every state of the gamewill be stored in the client application and them communicated to theserver. The communication language used for this communication wasdescribed in the application layer description above.

During the registration process the mode of payment which the userwishes to employ will be stored along with all relevant details into thedatabase. The user's credit card will be charged based on the number oflottery games that are played. If the user does not provide the correctdetails for payment the application will nor allow the user to launchthe game. The criteria for validation will be done by a 3rd party systemverifying the authenticity of the credit card payment mode.

Confirmation of transactions. For every transaction made the user willbe notified with following details. Transaction ID, date of transaction,transaction amount and date of lottery draw for games where the winneris not announced immediately.

All the winners will be notified utilizing the following modes ofcommunication. E-mail, SMS, an IVR (interactive voice response).

The following steps illustrate the process for application based gaming.

Step 1. The user will register on the gaming server website for thefirst time, see FIG. 5.

Step 2. The user will provide all the required information. USER NAME,MOBILE NUMBER, CREDIT CARD NUMBER, EXPIRY DATE, DATE OF BIRTH, IMAGE andPASSCODE/PASSWORD.

Step 3. After successful registration the user will login using theregistered Passcode/Password. Step 4. After successful login theapplication will provide a list of games supported from which the usercan select one form the menu.

Step 5. The user can start playing the game using the mobile devicekeypad or stylus.

Step 6. Once the game is complete the user will receive a notificationof the transaction.

Step 7. The user will receive a confirmation of the results via e-mail,SMS or an IVR call.

Another embodiment of the present invention is IVR based mobile lotterygaming. IVR (interactive voice response) is a general term for mobilephone-based voice value-added services. By dialing a designated number,mobile phone users are able to listen to or send information or evenparticipate in interactive activities like lottery games. The followingprocess explains the details of how IVR can be used to play mobilelottery games. FIG. 7 is a flowchart illustrating this process.

An IVR number is called from a mobile device which allows the user toregister 102. The registration process 104 allows the user establish anaccount with a server. The user can them login using their passcodeand/or selected image 106. If the incorrect passcode and/or image isentered 108 the user is instructed to enter this information again.After a number of unsuccessful login attempts, for example 5, the useris sent to the end of the program and not permitted to play the game110. If the user wants to continue they must repeat the registrationprocess 104 again. Once the user has logged in they can choose the gamethey wish to play from the IVR menu 112. For example the user may wishto play a PICK 3 Lottery game. Next at 114 the user will provide thearguments or select the numbers they wish to play on the keypad of themobile device or other data entering device. For example the user mayenter “02”, “34” and “45” on the keypad. The transaction is confirmed atstep 116. Depending on the game which is selected there will either bean immediate draw of the winning numbers 118 or a date will be given onwhich the winning numbers are to be drawn 120. If the drawing is at alater date the user can check back on their mobile device for thewinning number or can check other sources such as the television, alottery terminal, the newspaper, etc. The gaming application is thenended at 122.

A detailed description of the IVR based gaming process is as follows.The user registers of the gaming server registration website for thefirst time. During registration the user will be asked to select aPasscode/Password that will be used for all future transactions. FIG. 5illustrates the registration website. The following details are requiredto be provided by the user for registration. User name, mobile devicenumber, credit card number, expiry date, date of birth andpasscode/password.

After successful registration the user can start playing the lotterygame. The user will call the toll free IVR number for playing thelottery games. For example, when the user calls the toll free number(1-800-555-5555) the user will be connected to the IVR server. The userwill be greeted by voice prompts. The user will follow the voice promptsand enter the required details accordingly. The IVR will prompt the userto choose the game from the available menu. The prompts can be asfollows: 1—PICK 3; 2—PICK 6; 3—LOTTOPLUS; 4—KENOPLUS; 5—SCRATCH & WIN;etc. If the user selects 1 the game will be PICK 3. Every time the userwants to play the Passcode/Password must be entered. ThePasscode/Password will be received by the IVR in the form of DTMFsignals or Voice recognition.

To start the game the user provides the relevant inputs for the gameselected and completes the game. For example, if the user wants to playPICK 3, the user will pick three numbers as inputs to the game. The userthen enters the three numbers or says the three numbers (IVR with voicerecognition) after the prompts. During the registration process the modeof payment that the user wishes to use will be stored along with allrelevant details into the database. The user's credit card will becharged based on the number of lottery games that are played. If theuser does not provide the correct details for payment the applicationwill not permit the user to play the game. The criteria for validationwill be done by a 3rd party system verifying the authenticity of thecredit card payment mode. For every transaction made the user will benotified with the following details: Transaction ID, date oftransaction, transaction amount and date of lottery draw (for gameswhere the winner is not announced immediately). All of the winners willbe notified in the following modes of communication: e-mail, SMS, an IVRcall, etc.

The following steps illustrate IVR based gaming.

Step 1. The user calls the IVR to register for mobile lottery gaming.

Step 2. IVR provides all the details about the mobile lottery gaming andinformation required from the user to register like name, mobile number,credit card number, expiry date, age and passcode/password.

Step 3. After successful registration the user logs in using theregistered Passcode/Password.

Step 4. After successful login the IVR system will provide the list ofgames supported from which the user can select on to play.

Step 5. Based on the lottery game selected, the user can provide thearguments of numbers as described in FIG. 7. The user should enter thearguments or numbers from the mobile device keypad and the IVR receivesthe arguments through DTMF signals. The user and the IVR can alsoexchange information by interactive voice recognition and response.

Step 6. Once the entry is recorded in the server the user will receive anotification of the transaction.

Another embodiment of the present invention is WAP based lottery gaming.WAP is more than just browser software for a phone. It is a completesuite of protocols that tries to provide its capabilities on a multitudeof data-based wireless protocols. The WAP browser provides media toaccess the Internet on the mobile device by taking into account thelimited resources available in the mobile device. The following processexplains the details of how WAP based lottery gaming can be used to playmobile lottery games. FIG. 8 is a flowchart illustrating this process.

A WAP browser is launched from the mobile device 124. The registrationprocess 126 allows the user establish an account with a server. The usercan them login using their passcode and/or selected image 128. If theincorrect passcode and/or image is entered 130 the user is instructed toenter this information again. After a number of unsuccessful loginattempts, for example 5, the user is sent to the end of the program andnot permitted to play the game 132. If the user wants to continue theymust repeat the registration process 126 again. Once the user has loggedin they can choose the game they wish to play from the WAP menu 134. Forexample the user may wish to play a PICK 3 Lottery game. Next at 136 theuser will provide the arguments or select the numbers they wish to playon the keypad of the mobile device or other data entering device. Forexample the user may enter “02”, “34” and “45” on the keypad. Thetransaction is confirmed at step 138. Depending on the game which isselected there will either be an immediate draw of the winning numbers140 or a date will be given on which the winning numbers are to be drawn142. If the drawing is at a later date the user can check back on theirmobile device for the winning number or can check other sources such asthe television, a lottery terminal, the newspaper, etc. The gamingapplication is then ended at 144.

A detailed description of WAP based lottery gaming is as follows. Theuser registers of the gaming server registration website for the firsttime. During registration the user will be asked to select aPasscode/Password that will be used for all future transactions. FIG. 5is an example of the registration website. The user will be required toprovide the following details. The user's name, the mobile devicenumber, a credit card number, the expiry date of the credit card, theuser's date of birth and a passcode/password. After successfulregistration the user will login to the gaming server with the uniquePasscode/Password before playing the game. The user will start playingthe lottery game through the WAP browser on the mobile device. All thestates of the game will be stored in the server until the user logs offthe game. During the registration process the mode of payment that theuser wishes to utilize will be stored along with all relevant detailsinto the database. The user's credit card will be charged based on thenumber of lottery games which are played. If the user does not providethe correct details for payment the application will not permit the userto play the game. The criteria for validation will be done by a 3rdparty system reifying the authenticity of the credit card payment mode.For every transaction made the user will be notified with the followingdetails: transaction ID, date of transaction, transaction amount anddate of lottery draw (for games where the winner is not announcedimmediately). Once the payment transaction is complete the user will beimmediately notified. The winners will be notified by e-mail, SMS, anIVR call, etc.

The following steps illustrate WAP based gaming.

Step 1. The user launches the WAP browser to register for the mobilelottery gaming.

Step 2. The user enters all the information required from the user toregister.

Step 3. After successful registration the user logs in using theregistered Passcode/Password.

Step 4. After successful login the system will provide a list of thegames supported from which the user can select a game to play.

Step 5. Based on the lottery game the user can enter the arguments ornumbers in the browser as described above.

Step 6. Once the entry is recorded in the server the user will receive anotification of the transaction.

Another embodiment of the present invention is SMS based lottery gaming.Short Message Service (SMS) is a communication protocol allowing theinterchange of short text messages between mobile telephony devices. Thefollowing process illustrates how mobile phone users can use SMS to playlottery games on the mobile devices. FIG. 9 is a flowchart illustratingSMS based gaming.

A SMS is sent from the mobile device to register 146. The registrationprocess 148 allows the user establish an account. The user can themlogin using their passcode and/or selected image 150. If the incorrectpasscode and/or image is entered 152 the user is instructed to enterthis information again. After a number of unsuccessful login attempts,for example 5, the user is sent to the end of the program and notpermitted to play the game 154. If the user wants to continue they mustrepeat the registration process 148 again. Once the user has logged inthey can choose the game they wish to play from the menu at 150. Forexample the user may wish to play a PICK 3 Lottery game. Next at 150 theuser will provide the arguments or select the numbers they wish to playon the keypad of the mobile device or other data entering device. Forexample the user may enter “02”, “34” and “45” on the keypad. Thetransaction is confirmed at step 156. Depending on the game which isselected there will either be an immediate draw of the winning numbers158 or a date will be given on which the winning numbers are to be drawn160. If the drawing is at a later date the user can check back on theirmobile device for the winning number or can check other sources such asthe television, a lottery terminal, the newspaper, etc. The gamingapplication is then ended at 162.

A detailed description of SMS based gaming is as follows. The user willregister of the gaming server registration website for the first time.During registration the user will be asked to select a Passcode/Passwordthat will be used for all future transactions. FIG. 5 illustrates aregistration website. The user will be asked to provide the followingdetails. The user's name, the mobile device number, a credit cardnumber, the expiry date of the credit card, the user's date of birth anda passcode/password. The user will send a SMS to the server with therequired details for a game. The user's passcode/password, the name ofthe game and the arguments or selected numbers. For example, if the userwants to play a PICK 3 game, the user will select three numbers and senda SMS in the following text format: “PWD PICK3 23 45 12”. During theregistration process the mode of payment that the user wishes to utilizewill be stored along with all the relevant details into the database.The user's credit card will be charged based on the number of lotterygames that are played. If the user does not provide the correct detailsfor payment the application will not permit the user to play the game.The criteria for validation will be done by a 3rd party system verifyingthe authenticity of the credit card payment mode. For every transactionmade the user will be notified with the following details. Thetransaction ID, the date of transaction, the transaction amount, and thedate of the lottery draw (for games where the winner is not announcedimmediately). The winners will be notified by an e-mail, a SMS an IVRcall, etc.

The following steps illustrate SMS based gaming.

Step 1. The user sends a SMS to the SMSC gateway register for mobilelottery gaming.

Step 2. The user registers using a credit card number and PIN number.

Step 3. After successful registration the user sends a SMS to the SMSCgateway in the following format “PASSCODE/PASSWORD”, “Name of the Game”and “Arguments to the game”.

Step 4. Once the entry is recorded in the server the user will receive anotification of the transaction as a SMS confirmation.

Step 5. If the lottery game provides immediate results, like a scratchand win game the user will be notified immediately. In the case of adelayed drawing, the user will be notified of the drawing date.

All patents and publications mentioned in this specification areindicative of the levels of those skilled in the art to which theinvention pertains. All patents and publications are herein incorporatedby reference to the same extent as if each individual publication wasspecifically and individually indicated to be incorporated by reference.

It is to be understood that while a certain form of the invention isillustrated, it is not to be limited to the specific form or arrangementherein described and shown. It will be apparent to those skilled in theart that various changes may be made without departing from the scope ofthe invention and the invention is not to be considered limited to whatis shown and described in the specification and any drawings/figuresincluded herein.

One skilled in the art will readily appreciate that the presentinvention is well adapted to carry out the objectives and obtain theends and advantages mentioned, as well as those inherent therein. Theembodiments, methods, procedures and techniques described herein arepresently representative of the preferred embodiments, are intended tobe exemplary and are not intended as limitations on the scope. Changestherein and other uses will occur to those skilled in the art which areencompassed within the spirit of the invention and are defined by thescope of the appended claims. Although the invention has been describedin connection with specific preferred embodiments, it should beunderstood that the invention as claimed should not be unduly limited tosuch specific embodiments. Indeed, various modifications of thedescribed modes for carrying out the invention which are obvious tothose skilled in the art are intended to be within the scope of thefollowing claims.

1. Mobile lottery gaming on a wireless mobile device comprising: amobile device for use in wireless communicating with a remote gameserver; said game server having a stack of wireless applicationprotocols including a memory for storing information to identify amobile device and for routing and parsing of messages to said mobiledevice; an application layer residing on each said mobile devicecontaining a number of lottery game applications to be played; apresentation layer residing on said mobile device, said presentationlayer having a cryptographic module to provide security services duringdata communication and a message encoder for encrypting of data passedthrough an application router in communication with said applicationlayer; and a transport layer residing on said mobile device for receiptof data communication from said presentation layer and directing to anetwork layer permitting two-way communication between said mobiledevice and said game server.
 2. The system of claim 1 wherein saidapplication layer is further defined as a model-view-controller forcommunicating data between an event and a display on said mobile device.3. The system of claim 1 wherein said message encoder provides ComMLprotocol data encoding prior to routing of a message to said transportlayer.
 4. The system of claim 1 wherein said transport utilizes TCP/IPprotocols for communication between an application of said mobile deviceand said game server.
 5. The system of claim 1 wherein said transportutilizes SMS protocols for communication between an application of saidmobile device and said game server.
 6. The system of claim 1 whereinsaid application layer communicates with a backend gaming system havingauthentication services before providing data to said application layer.7. The system of claim 1 wherein payment authorization can betransmitted from said mobile device to said server.
 8. The system ofclaim 1 including an interactive voice response system utilized tocommunicate between said mobile device and said server.
 9. The system ofclaim 1 wherein said network layer communicates by a GPRS network or a 1xEV-DO network.
 10. The system of claim 1 wherein a WAP is utilized tocommunicate between said mobile device and said server to transmitinformation.
 11. The method of claim 1 wherein a short message serviceis utilized to communicate between said mobile device and said server toplay said games.
 12. Mobile lottery gaming on a wireless mobile devicecomprising: a mobile device for use in wireless communicating with aremote game server; said game server having a stack of wirelessapplication protocols including a memory for storing information toidentify a mobile device and for routing and parsing of messages to saidmobile device; an encrypted file residing on each said mobile device,said encrypted file containing information which identifies each saidmobile device to said game server permitting expedited client sidelogin/password credential verification; an application layer residing oneach said mobile device containing a number of lottery game applicationsto be played, said application layer having a model-view-controller forcommunicating data between an event and a display on said mobile device;a presentation layer residing on said mobile device, said presentationlayer having a cryptographic module to provide security services duringdata communication and a message encoder for encrypting of data passedthrough an application router in communication with said applicationlayer, said message encoder employing a ComML protocol data encodingprior to routing of a message to said transport layer; and a transportlayer residing on said mobile device for receipt of data communicationfrom said presentation layer and directing to a network layer permittingtwo-way communication between said mobile device and said game server.13. The system of claim 1 wherein said transport utilizes TCP/IPprotocols for communication between an application of said mobile deviceand said game server.
 14. The system of claim 1 wherein said transportutilizes SMS protocols for communication between an application of saidmobile device and said game server.
 15. The system of claim 1 whereinsaid application layer communicates with a backend gaming system havingauthentication services before providing data to said application layer.16. The system of claim 1 wherein payment authorization can betransmitted from said mobile device to said server.
 17. The system ofclaim 1 including an interactive voice response system utilized tocommunicate between said mobile device and said server.
 18. The systemof claim 1 wherein said network layer communicates by a GPRS network ora 1 xEV-DO network.
 19. The system of claim 1 wherein a WAP is utilizedto communicate between said mobile device and said server to transmitinformation.
 20. The method of claim 1 wherein a short message serviceis utilized to communicate between said mobile device and said server toplay said games.